IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end subscribers will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) and ETSI TISPAN group to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a subscriber-to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber that the subscriber is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. ASs provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which ASs should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's or subscriber's Subscriber Profile.
A Ut interface (or more correctly “reference point”) has been specified between the AS and a user equipment (UE) (e.g. 3GPP Technical Specification 23.002). The Ut interface enables a user to manage information relating to his or her services, e.g. creation and assignment of Public Service Identities, management of authorisation policies that are used for example by presence services, conference policy management, etc. The Ut interface allows in particular a user to manipulate Extensible Markup Language (XML) data associated with an AS and which defines how certain services are provided to that user. XML documents are handled by XML Document Management Servers (XDMSs), which are typically co-located with ASs. In use, an XDMS stores service data into a Home Subscriber Server (HSS) (as transparent data), which is then retrieved by the AS at service invocation.
The UE may comprise or represent any device used for communications. Examples of UE that may be used in certain embodiments of the described network(s) are wireless devices such as mobile phones, terminals, smart phones, portable computing devices such as lap tops, handheld devices, tablets, netbooks, computers, personal digital assistants and other wireless communication devices, or wired communication devices such as telephones, computing devices such as desktop computers, set-top boxes, and other fixed communication devices.
ETSI TISPAN has adopted the XML Configuration Access Protocol (XCAP), as specified in IETF RFC 4825, for use over the Ut interface and which facilitates the use of http methods, i.e. GET, PUT, and DELETE, to operate on XML data stored in the HSS, via an XDMS. ETSI 183 023 presents a refined XCAP protocol for manipulating data relating specifically to PSTN/ISDN simulation services that will be provided within Next Generation Networks (NGN). Such services include for example voice mail, call forwarding, call barring, etc, with each service being defined within the standard by an XML “schema” which represents an XML template for incorporation into user XML documents.
The XML documents defining customer services and settings are handled by the XDMS. A so-called “Sh” interface allows the XDMS to communicate with the HSS. A network operator may initially install pre-configured XML data, based upon the standardised XML schema, on a per-user basis into the HSS, and to subsequently amend the installed XML data via the XDMS. The management network additionally provides a mechanism whereby a user can edit his/her associated XML document. For this purpose, a Ut client can be installed within the UE and/or within a web portal. As discussed above, the Ut client uses the XCAP protocol to retrieve (either the whole document or a fragment thereof) and amend the XML document (or fragment) associated with the user. It will be appreciated that the XDMS reacts to a retrieval request from a user via the UE or web portal by obtaining the relevant XML data from the HSS and delivering this to the user via the UE or web portal over the Ut interface.
The Ut client fetches the stored data for the user from the XDMS by sending an XCAP GET request to the XDMS over the Ut interface. An Aggregation Proxy may be used to authenticate these requests. The XDMS fetches the data from the HSS over the Sh interface and sends it back to the Ut client in a Ut response message. The Ut client displays information and options to the user. Whilst the XDMS is able to allow and reject requests by a user to change the XML data, as currently defined the relevant standard does not have any mechanism to include information related to unconditional or immediate based service rules or to limit further changes to these types of service rules by the user. A user can download to the UE or web portal the XML document relating to their service set, with the UE or web portal rendering the service set to the user by displaying all service settings, regardless of whether or not the XDMS will actually accept a request from the user to change their service settings and/or associated service rules. Such an approach will inevitably result in unhappy and confused users.